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© Automatic programming system. 



© To automatize programming in a software devel- 
opment as much as possible, a trading-off operation 
for producing a program structure at the time of 
program design, a failure mode and effect analysis 
operation and a design review operation are all 
automatized, thus reducing time required for these 
operations. The design and test are directly coupled 
to each other so that design data at the time of 
design can be automatically utilized effectively at the 
time of test, thus saving man-hour for the test, 
reducing the test time and permitting effective pro- 
. gramming, 
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AUTOMATIC PROGRAMMING SYSTEM 



Background of the Invention 



[Field of the Invention] 

This invention relates to an automatic program- 
ming system for permitting programming in soft- 
ware development to be done as mechanically as 
possible. 



[Description of the Prior Art] 

As prior art automatic programming system, 
there is one in a narrow sense, which automatically 
generates program source codes from block dia- 
grams based on PAD system or the like as dis- 
closed in a treatice entitled "Automatic Personal 
Computer Program Generation Based on PAD 
Specifications" (Treatice No. 3L-10) in Transactions 
II of the 36-th National Lecture Meeting of Informa- 
tion Processing Society of Japan. A broad-sense 
automatic programming system for supporting and 
automating all the processes of designing, manu- 
facture and test from the definition of requests in 
the design of programs till the test is disclosed in a 
treatise entitled "— Basic Concept —Consistent 
Real-Time System Development System" (Treatise 
No. 5M-10) disclosed in Transactions If of the 36th- 
National Lecture Meeting of Information Processing 
Society of Japan. The above-mentioned narrow- 
sense automatic programming system is included 
in the broad-sense automatic programming system. 
For this reason, the broad-sense automatic pro- 
gramming system will now be described as the 
prior art automatic programming system in connec- 
tion with its construction and operation. 

Fig. 6 is a block diagram showing a prior art 
example of software produced on the basis of the 
explanation of the afore-noted treatise " — Basic 
Concept — Consistent Real-Time System Develop- 
ment System". In Fig. 6, reference numeral 102 
designates request definition analysis means for 
analyzing the definition of requests concerning the 
function or scale at the time of start of design on 
the basis of request specifications, 103 block dia- 
gram production means for producing commonly 
termed block diagrams such as data flow diagrams, 
control flow diagrams, module diagrams and PAD 
diagrams from the result of analysis of the means 
102, 104 automatic programming production means 
for automatically producing source codes which 
can be executed by a computer on the basis of a 
block diagram, and 105 program test means for 



testing a program using source codes. These 
means are assembled as softwares in a computer. 
Usual computers available in the market are used 
as hardware. 

s The operation will now be described. The re- 

quest definition analysis means 102 performs re- 
quest definition analysis on the basis of request 
specifications of functions and scale. In the prior 
art, it is not performed automatically by any ma- 

to chine, but most of them are performed manually by 
specialists. The contents of the manual request 
definition analysis performed by men are to deter- 
mine program constitution satisfying request speci- 
fications at the time of design by trading-off. The 

75 block diagram production means 103 produces 
data flow diagrams, control flow diagrams, module 
diagrams and PAD diagrams as a result of the 
request definition analysis. The production of these 
diagrams is automatized, although not perfectly. 

20 The automatic programming production means 104 
automatically produces source codes (programs) of 
a machine language satisfying the request speci- 
fications according to the produced block diagrams 
or the like. Lastly, the program test means 105 

25 performs tests on programs of the above-men- 
tioned source code type. The program test is per- 
formed to check if the request specifications at the 
time of the design are satisfied. It is made possible 
to conduct the test while following the program 

30 execution with the eyes for providing increased test 
efficiency. If the request specifications are not sat- 
isfied, it is necessary to perform programming 
afresh. 

In this way, the design reviewing operation for 

3$ reviewing the design results and pointing out and 
correcting difficiencies has been done entirely 
manually. For this reason, no design reviewing 
means as software for the purpose of automation 
has ever been assembled in the prior art system. 

40 Further, no means or software for performing 
FMEA (failure mode and effect analysis) at the time 
of the design has been assembled, and again this 
analysis has been performed manually. 

Since the prior art automatic programming sys- 

45 tern has the above construction, the program con- 
stitution trading-off operation, failure mode and ef- 
fect analysis based on block diagrams and design 
reviewing operation, these operations being per- 
formed at the time of the design, are not automa- 

so tized, but are done manually. Therefore, many soft- 
ware design specialists are required, and enormous 
time is required for each individual operation. Fur- 
ther, the production of program test data based on 
the failure mode and effect analysis results is not 
automatized. Therefore, although the design and 
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manufacture are directly coupled together, the de- 
sign and test ar not directly coupled together but 
are separated from each other. This means that the 
results of design cannot be effectively utilized at 
the tim of the test unless manual operation is had 
resort to. 



Summary of the Invention 



This invention has been intended in order to 
solve the above problems, and its object is to 
provide an automatic programming system, which 
automatizes the trading off operation of producing 
program structure, failure mode and effect analysis 
and design reviewing operation at the time of the 
program design, thus reducing time required for 
each individual operation, and directly coupling the 
design and test to permit automatic and effective 
utility of the design data at the time of the test, 
thus automatizing the producing of the test data, 
saving man-hour at the time of the test and reduc- 
ing test time so as to realize effective program- 
ming. 

According to the invention, there are provided 
program constitution trading-off means 2 for per- 
forming trading-off of the program constitution ac- 
cording to software request specifications to obtain 
an optimum combination of components constitut- 
ing the program, block diagram production means 
3 for producing block diagrams m including signal 
system diagrams from the results of the optimum 
combination of components t , failure mode and 
effect analysis means 4 for performing failure mode 
and effect analysis of program from the block dia- 
grams m to produce an analysis sheet n, simula- 
tion means 5 for performing simulation for confirm- 
ing the operation of program constituted by block 
diagrams m, software design reviewing means 6 
including a learning section 6a for acquisition and 
learning a design knowledge of the like about soft- 
ware from the process of production of the analysis 
sheet n and the optimum combination of compo- 
nents I, knowledge base section 6b for storing the 
acquired design knowledge or the like and infer- 
ence section 6c for effecting inference by using the 
acquired design knowledge or the like, automatic 
program production means 7 for producing pro- 
gram source codes 0 from the block diagrams m, 
automatic program test data production means 8 
for producing program test rules p from the analy- 
sis sheet n and program test means 9 for perform- 
ing program tests on program source codes 0 on 
the basis of the rest rules p. 

The above and other objects, features and ad- 
vantages of th invention will become more appar- 
ent from the following description when taketf in 



conjunction with the accompanying drawings. 



Brief Description of the Drawings 

s 

Fig. 1 is a block diagram showing an em- 
bodiment of the invention; 

Fig. 2 is a view showing a format of an 
w FMEA sheet (analysis sheet) produced by a failure 
mode and effect analysis means shown in Fig. 1 ; 

Fig. 3 is a flow chart for explaining the 
operation of the failure mode and effect analysis 
means; 

75 Rg. 4 is a flow chart for explaining the 

operation of the automatic program test data pro- 
duction means shown in Rg. 1 ; 

Rg. 5 is a flow chart for explaining a series 
of operations of all the means assembled in the 
20 automatic programming means; and 

Rg. 6 is a flow chart for explaining a prior art 
automatic programming system. 

25 Description of tine Preferred Embodiment 



Now, an embodiment of the invention will be 
described in conjunction with an embodiment 
30 thereof. Rg. 1 shows the entire constitution of an 
embodiment of the invention, which is a software 
assembled in an automatic programming system 1 . 
The automatic programming system 1 uses as a 
processor a usual computer available as a hard- 
35 ware in the market. 

Referring to Rg. 1. reference numeral 1 des- 
ignates the automatic programming system as a 
whole. Numeral 2 designates program structure 
trading-off means assembled as a software in the 
40 automatic programming system 1. Numeral 3 block 
diagram production means for producing block dia- 
grams including signal system diagrams according 
to the results of the program structure trading-off 
means 2. Numeral 4 designates failure mode and 
45 effect analysis means for performing failure mode 
and effect analysis of a program according to the 
results of the block diagram production means 3 to 
produce a failure mode and effect analysis sheet. 
Numeral 5 designates simulation means for per- 
so forming simulation for confirmation of operation 
from the block diagrams. Numeral 6 designates 
software design review means including a learning 
section 6a, a knowledge base section 6b and an 
infer nee section 6c. The learning section 6a ef- 
55 fects acquisition and learning of software design 
knowl dg from results 10 of processing of the 
program structure trading-off means 2 and the fail- 
ure mode and effect analysis means 4. The knowl- 
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edge base section 6b stores knowledge produced 
by the learning section 6a and design knowledge. 
The inferenc section 6c performs inferenc by 
using the knowledge stored in the knowledge base 
section 6b. Numeral 7 designates automatic pro- 
gram production means for automatically producing 
source codes of program from the results of the 
block diagram production means 3. Numeral 8 des- 
ignates automatic program test data production 
means for automatically producing program test 
data from the results of the failure mode and effect 
analysis means 4. Numeral 9 designates program 
test means for performing program tests according 
to the results obtained from the automatic program 
production means 7 and the automatic program 
test data production means 8. 

With the automatic programming system hav- 
ing the above construction, with interlocked opera- 
tion of the means 2 to 9 the designing, production 
and test of program can be done substantially 
entirely automatically. Now, the function of the 
means 2 to 9 will be described in detail. 

A program structure is generally comprised of 
minimum elements called sub-routines or modules. 
These elements are hereinafter called parts. Parts 
include objects or classes so called in the filed of 
knowledge engineering as well as the sub-routines 
and modules. A program unit, which comprises a 
plurality of such parts and has a certain function, is 
called a component Data of these parts and com- 
ponents are preliminarily stored in the knowledge 
base section 6b in the software design review 
means 6. 

The program structure trading-off means 2 per- 
forms trading-off of a program structure according 
to software request specifications. The software 
request specifications prescribe function, perfor- 
mance, scale, etc. required for a software 
(program) to be produced. Trading-off is effected 
between these specifications and realizable pro- 
gram structure to determine a structure which 
meets the required specifications as much as pos- 
sible. The structure is determined roughly in two 
classes. In the first step, basic structures of pro- 
gram functions necessary for realizing rough re- 
quest functions among the required specifications 
are determined by trading-off. Then, further de- 
tailed structures for realizing each individual pro- 
gram function are determined. 

When determining the basic structures of the 
program functions and the detailed program struc- 
tures, the program structure trading-off means 2 is 
provided with evaluation standard parameters for 
optimization to perform optimization. Th evaluation 
standard parameters includ process speed, seal , 
transplantation property, cost and results of use of 
program. The process of optimization noted above 
adopts a process argorithm utilizing a "dynamic 



planning process" in a mathematical planning 
method hitherto utilized and a "constraint solving 
theory" noted in the fi Id of the knowledge en- 
gineering. 

s Furhter, the programme structure trading-off 

means 2 has a function of performing the program 
structure trade-off described above in accordance 
with interactions with a designer. This function will 
be described hereinunder. 

io Where the program structure trade-off is per- 

formed as a colloquial process, with an input of a 
specification of a software function required for a 
program to be designed from the designer, compo- 
nent data meeting the requested specifications or 

is equivalent data is selected from among the compo- 
nent data bases in the knowledge base section 6b 
in the software design review means 6 and dis- 
played as combination data on a graphic display 
screen. The component data bases include the 

20 process speeds, scales, transplantations properties, 
costs, input/output conditions, results of use, etc., 
of the program as evaluation parameters. The de- 
signer can determine an optimum component com- 
bination l of the basic constitution by performing 

25 the optimization process by using the requested 
specifications and these evaluation parameters and, 
if necessary, altering the component combination 
by the coltiquial process. Likewise, a combination 
of parts is determined with respect to a detailed 

30 program structure consisting of parts. 

The block diagram producing means 3 pro- 
duces the program block diagram m based on the 
basic structures of the program function and the 
detailed program structures produced as the re- 

3$ suits of the program structure trading-off means 2. 
The block diagrams m are a program for perform- 
ing the same processings as a program, drawing 
general block diagrams, even though the signal 
system diagrams are contained therein. 

40 The failure mode and effect analysis means 4 

performs failure mode and effect analysis 
(abbreviated FMEA) on the basis of the program 
block diagrams m and produces the FMEA sheet n 
from the results of analysis. 

45 The FMEA process ia an analysis process pop- 

ular as a system engineering analysis process and 
performed at the time of the design. According to 
the invention, this FMEA process is applied to the 
failure mode and effect analysis of program. In 

so case of the software (program), the concept of the 
above parts and components is introduced, and the 
operation of this FMEA process is introduced into 
th failure mode and effect mode analysis of pro- 
gram. 

55 The program d signer executes the FMEA pro- 

cess while effecting colloquial process with the 
automatic programming system 1. More specifi- 
cally, the process is done with an answer input by 
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a specialist designer to a question displayed on the 
graphical display. 

Th failure mode and effect analysis means 4 
comprises an FMEA format production program 
and a question generation process program. The 
operations of these programs will now be de- 
scribed in detail. 



(a) FMEA format production program 

This program is for producing a format of the 
FMEA sheet on the basis of the FMEA process. It 
has a function similar to the flow of process of a 
program for producing a format of a usual table, 
and it is produced automatically. Fig. 2 shows an 
example of the format of the FMEA sheet used in 
this program. In the Figure, columns 21 to 30 have 
names concerning the contents to be stated in the 
colloquial process. These columns are provided by 
a division usually adopted in the FMEA process. 



(b) Question generation process program 

This program is for generating questions to fill 
specific contents in each vacant column of the 
FMEA sheet produced by the above FMEA format 
production program and displaying these questions 
on the graphical display screen. Then, it is for 
taking answers of the specialist (designer) to the 
questions and filling corresponding FMEA sheet 
columns with the answers. These operations are 
similar to those in case of a usual colloquial pro- 
cess program. Fig. 3 shows a flow chart of a 
specific example of a sequence of questions gen- 
erated in the order of a program process for ex- 
plaining the operations of the program process in 
further detail. As the specialist inputs sequential 
answers to questions 41 to 50 from a keyboard of 
the automatic programming system 1. the program 
functions to fill the input answers into each column 
of the FMEA sheet to complete the FMEA sheet 
(analysis sheet) n. 

Further, each of the values contained in the 
knowledge base section 6b of the software design 
review means 6 are quoted at the time of produc- 
ing the FMEM sheet (analysis sheet) n. 

Further, the FMEA sheet n based on the FMEA 
process noted above may be completed by a collo- 
quial process between the automatic programming 
system 1 and the specialist by using the failure 
mode and effect analysis means 4 consisting of the 
two programs (a) and (b) described before. 

The simulation means 5 Is a program for per- 
forming simulation of program process operation 
including confirmation of operation as to whether it 
is possible to attain a function satisfying required 



specifications (hereinafter referred to as design 
specifications) recognized in the stage of design 
according to the program block diagrams m pro- 
duced by the block diagram production means 3 

s through a trading-off process. This program is for a 
process operation similar to a general simulation 
program. If it is found as a result of the simulation 
that no function satisfies the design specifications, 
the routine goes back to the program constitution 

10 trading-off means 2 to review the program constitu- 
tion and performs program constitution trading-off 
afresh. These operations are done repeatedly until 
a function satisfying the design specifications is 
obtained. 

15 The software design review means 6 com- 

prises the learning section 6a, the knowledge base 
section 6b and the inference section 6c as shown 
in Fig. 1. In the knowledge base section 6b parts 
designed in the past and having results of trading- 

20 off are accumulated. The software design review 
means 6 has the following three different functions, 
which will now be described in detail together with 
their operations. 



(1) Design knowledge acquisition and learning 
function 

As shown in Fig. 1. design knowledge and 
30 rules are extracted from the results 10 of pro- 
cesses of the program constitution trading-off 
means 2 and the failure mode and effect analysis 
means 4 and are arranged to produce knowledge 
for design reviewing concerning software, and this 
35 knowledge is stored as knowledge base in the 
knowledge base section 6b. 

(2) Design evaluation function 

40 

The design is reviewed using the knowledge 
for design reviewing concerning a software stored 
in the knowledge base section 6b, and indeficien- 
cies of the design are pointed out to provide data 
45 11 reflected on design operations using the pro- 
gram constitution trading-off means 2 and the fail- 
ure mode and effect analysis means 4 for effecting 
evaluation, improvement and confirmation of the 
program design. 

50 

(3) Design consultation function 

The knowledge base is retrieved intelligently in 
55 response to an inquiry from a designer to provide 
various information necessary for the design. 

The above three functions (1) to (3) can be 
provided by an int rlocked operation of the learning 
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section 6a, the knowledge base section 6b and the 
inference section 6c constituting the software de- 
sign review means 6. These section will now be 
described. 



(A) Learning section 6a 

The learning section 6a mainly has a role of 
securing and studying design knowledge and per- 
forms intelligent process using the knoiwledge 
base section 6b and inference section 6c. 

By the term "intelligent" is meant taht there is 
some capacity of effecting some inference on the 
basis of knowledge base and inference function. 
"Some inference** means what is generally defined 
in the field of the knowledge engineering, for in- 
stance, deductive inference, inductive inference 
and analogical inference. 

The learning section 6a can automatically pro- 
duce knowledge for design reviewing concerning a 
software by heuristic or experimental learning on 
design knowledge acquired by using the above 
inference functions and knowledge base. 

By the term "heuristic learning " is meant learn- 
ing by the above inductive inference or the like. 
Further, fragments of knowledges acquired are 
classified and arranged in a systematic structure to 
be stored in the knowledge base for pointing out 
indeficiencies of knowledges. 



(B) Knowledge base section 6b 

In the knowledge base section 6b is stored 
what is obtained by arranging and editing various 
pieces of knowledges and components and parts 
for programs. 

There are four kinds of knowledges as follows. 



(i) Past design data 

Design data expressed by characters, numer- 
als, drawings and other images, malfunction data, 
check lists, etc., concerning past examples of pro- 
gram design (including parts and components) 



(it) Design data acquired this time 

Design data acquired from the results of pro- 
cesses of the program constitution trading-off 
means 2 and the failure mode and effect analysis 
means 4 



(iii) Learning result data 



Design and design review knowledge concern- 
ing software obtained from design data secured in ( 
i ) and ( ii ) as a result of learning using the 
inference function 



(iv) Design model data 

These data are also called "object models" in 
ro the field of knowledge engineering and express 
design objects themselves. For instance, the data 
concerning free and ideal design based on initially 
requested specifications and free from trade-off 
restrictions. The four different kinds of knowledges 
is described above, are stored in various forms in the 
knowledge base section 6b. 

The "various forms" here are generally called 
the knowledge nomencalture in the field of knowl- 
edge engineering, and they mean, for instance, 
20 "production system", "frame 1 *, "blackboard 
model", "meaning network", "predicative theory" 
and "object". 



25 (C) Inference section 6c 

The inference section 6c is a mechanism in- 
dependent of the learning section 6a and knowl- 
edge base section 6b, and it performs inference 
oo using the knowledge stored in the knowledge base 
section 6b. 

The "inference" means a "function of deriving 
from known data a piece of data, which is the same 
in the meaning, or a piece of data, which is in- 

35 eluded in that data but is in a different expression 
at least in an elucidative form", and a syllogism is 
included in this inference. 

The inference section 6c, however, is provided 
not only with the syllogism but also with various 

40 other inference functions generally defined in the 
field of the knowledge engineering such as induc- 
tive inference, analogical inference and default in- 
ference. 

As is obvious from the above, the software 
45 design review means 6 consisting of the learning 
section 6a, knowledge base section 6b and infer- 
ence section 6c is provided with design knowledge 
acquisition and learning section, design evaluation 
function and design consultation function and use- 
50 ful as design support means for supporting soft- 
ware design and reviewing thereof. 

The automatic program production means 7 
performs an operation of producing program 
source codes o on th basis of block diagrams m 
55 produced by the block diagram production means 
3. The block diagrams m consist of parts called 
sub- routines and modules, and they can be auto- 
matically produced in relation to pertinent source 
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codes o on the basis of part data bases.-. 

The automatic program test data production 
m ans 8 performs an operation of automatically 
producing program t st data from the results of 
analysis of each failure mod executed by the 
failure mode and effect analysis means 4 and the 
resultant effect. Here, the program test data is 
called test (diagnosis) rules p. Various indeficiency 
cases are examined, and corresponding failures 
are distributed in advance. These rules are sup- 
plied to the knowledge data base section of the 
program test means 9 and serve as test rules p 
corresponding to diagnostic decision standards for 
program test. 

Fig. 4 is a flow chart showing a flow of process 
for explaining the operation of the automatic pro- 
gram test data production means 8. In the Figure, 
processes 61 to 63 and 65 are executed automati- 
cally. In a process 64. the contents of a program 
diagnosis rule automatically produced in the pro- 
cesses 61 to 63 are checked. If necessary, a 
process of correction by the specialist is included. 
The corrected program diagnosis rule (or test rule) 
p obtained after final check is stored in the knowl- 
edge data base section of the program test means 
9 to be utilized for program test 

The program test means 9 performs test on a 
program source code obtained from the automatic 
program production means 7 according to the pro- 
gram diagnosis rule (test rule) p produced by the 
automatic program test data production means 8. 
The program test means 9 performs an operation 
similar to the case of software (program) called 
"diagnostic expert system" in the field of the 
knowledge engineering and the artificial intelli- 
gence. It includes a knowledge data base section 
and an inference function section (these sections 
being not shown) and can perform program test. 

In the knowledge data base section, program 
diagnosis rules (test rules) p for program test are 
stored. The inference function section consists of 
general argorithms called "inference engine" in the 
field of the knowledge engineering and the artificial 
intelligence. An argorithm for inferring a result by 
the syllogism or like process is provided in soft- 
ware, and the diagnosis rules p are used when 
inferring a diagnosis result from a gathering that "it 
is B if it is A w . 

While the construction, operation and effect of 
the individual means assembled as software in the 
automatic programming system 1 have been de- 
scribed, the relation among the individual means 
and overall operation and effect of these means are 
shown in the form of flow chart in Fig. 5. 

As shown in Fig. 5, the program structure 
trading-off means 2 first performs trading off of the 
basic structure of program function according to 
ideal requested specifications of software design 



(STEP 71). According to the result of trading-off the 
block diagram production means 3 produces a 
basic block diagram of program function (STEP 
72). According to this basic block diagram of pro- 
5 gram function, the simulation means 5 performs 
basic simulation of program function for confirming 
basic operation of program function (STEP 73). If 
the basis of the requested function is satisfied, the 
routine goes to a next step 74. Otherwise, the 
w routine goes back to the step 71. In the step 74, 
the program failure mode and effect analysis 
means 4 performs basic failure mode and effect 
analysis of program function according to the basic 
block diagram thereof. As a result, a FMEA sheet is 
75 produced. 

Then, the software design review means 6 per- 
forms basic design review of program function for 
reviewing the design operations (STEP 75). In a 
next step 76, a check is done on the result of the 
20 design review as to whether it is necessary to 
change the basic structure of program function. If 
the check yields YES, the routine goes back to the 
step 71 of trading off the basic structure of pro- 
gram function to perform the process as described. 
25 The step 75 of program function design review 
may, if necessary, be executed after each of the 
steps described above, for instance the step 71 of 
trading off the basic structure of program function. 
When no change of the basic structure of pro- 
30 gram function is necessary, the routine goes to a 
step 77 of trading off detailed program structures. 
Like the step 71 of trading off the basis structure of 
program function, a detailed structure block dia- 
gram is produced after the trade-off step 77 (STEP 
35 78). Then, a simulation step 79 is executed. Subse- 
quently, a step 80 of failure mode and effect analy- 
sis on details of program is executed to produce 
the FMEA sheet. Then design review is done with 
respect to the detailed program structure (STEP 
40 81). This step 81 .of design review may, if neces- 
sary, be executed after the step 77 of trading off 
detailed programme structure as well. If it is found 
that it is necessary to change the basic structure of 
program function in addition to the detailed pro- 
45 gram structure change (STEP 82), the step 71 of 
trading off the basic structure of program function 
should be executed again. In this case, the routine 
goes back to the first step 71 . 

When the FMEA sheet production is completed 
50 with completion of the steps concerning the basic 
structure of program function and detailed program 
structure, an automatic program production step 83 
is executed to produce' program source codes. 
Then, the automatic program test data production 
55 means 8 executes an automatic program test data 
production step 84 according to the FMEA sheet 
produced to produce program diagnosis rules, 
which are stored in the knowledge data base sec- 
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tion of the program test means 9. Finally, the 
program test means 9 performs a program test 
step 85. thus bringing an end to the routine. 

In the above embodiment the diagnosis rules 
stored in the knowledge data base section of the 
program test means 9 are in the form that "if it is B 
it is A". However, this form of diagnosis rule is by 
no means limitative, and it is possible to adopt any 
other diagnosis rule form such as "frame", 
"blackboard model", "meaning network*, 
"predicative logic" and "object-, or a plurality of 
these forms may be adopted in combination. Also, 
the program test means 9 may adopt other infer- 
ence functions than the syllogism, for instance, 
inductive inference, analogical inference and de- 
fault inference generally defined in the field of the 
intelligence engineering. 

Further, the result of the program test means 9, 
like the results 10 obtained form the program struc- 
ture trading-off means 2 and program failure mode 
and effect analysis means 4, may be supplied to 
software design review means 6 so that the result 
of program test may be utilized for the production 
of knowledges for software design reviewing. 

Furhter, while in the above embodiment the 
means 2 to 9 are all constituted by software, it is 
also possible to adopt hardware or firmware or 
combination thereof so long as similar functions 
and performance can be obtained. As examplies of 
such hardware and firmware, there are a neuro 
chip, which is a semiconductor chip implementing 
a neural network (nerve circuit network), and a 
fuzzy chip for performing a fuzzy set operation. 
The means 2 to 9 may be constituted such that 
hardware and firmware including these chips co- 
exist. 

Further, while a usual computer is used as a 
processor for each of the means 2 to 9, there is no 
limitation on the kind of computer so long as the 
processes of these means can be attained. Further, 
not only a single computer but also a plurality of 
computers may be employed according to the con- 
tents of processes of the means 2 to 9. 

Further, while the date of parts and compo- 
nents used in the program structure trading-off 
means 2 are contained in the knowledge base 
section 6b, these data may as well be stored 
distributedly in separate data bases other than the 
knowledge base section 6b. 

Further, while the above embodiment has con- 
cerned with a system of automatizing the program- 
ming operation in a broad sense including all the 
steps of software design, production and test, the 
same effects as described above may also be 
obtained when the invention is applied to software 
development support systems or semi-automatic 
programming systems for supporting operations 
that are performed by men. 



As has been described in the foregoing, ac- 
cording to the invention eight different means for 
automatizing the operations of software design, 
production and test are assembled as software in a 

s computer such that the individual means are op- 
erable in an interlocked relation to one another, it is 
possible to realize same man-hour, automatize and 
increase speed of the operations of software de- 
sign, design review and program production. 

70 The features disclosed in the foregoing de- 

scription, in the claims and/or in the accompanying 
drawings may, both, separately and in any com- 
bination thereof, be material for realising the inven- 
tion in diverse forms thereof. 

T5 

Claims 

1 . An automatic programming system compris- 
20 ing program constitution trading-off means for per- 
forming trading-off of a program constitution ac- 
cording to software request specifications to obtain 
an optimum combination of components constitut- 
ing the program, block diagram production means 

25 for producing block diagrams including signal sys- 
tem diagrams from a result of the optimum com- 
bination of the components, program failure mode 
and effect analysis means for performing failure 
mode and effect analysis of the program from the 

so block diagrams to produce an analysis sheet, sim- 
ulation means for performing simulation for con- 
firming the operation of the program constituted by 
the block diagrams, software design reviewing 
means including a learning section for acquisition 

35 and learning design knowledge or the like about a 
software from the source of production of the com- 
bination of the optimum combination of the compo- 
nents and the analysis sheet, a knowledge base 
section for storing the acquired design knowledge 

40 or the like and an inference section for effecting 
inference by using the acquired design knowledge 
or the like, automatic program production means 
for producing program source codes from the block 
diagrams, automatic program test data production 

45 means for producing program test rules from the 
analysis sheet and program test means for per- 
forming program tests on the program source 
codes on the basis of the test rules. 

2. An automatic programming system accord- 
so ing to claim 1, wherein said program constitution 

trading-off means has evaluation reference param- 
eters for optimizing trading-off and is provided with 
a function of effecting an optimization process and 
also effecting trading-off in colloquy with a designer 
55 to determine a basic structure of program functions 
necessary for realizing rough requested functions 
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in requested software specifications and then de- 
termine detailed structures for realizing each pro- 
gram function. 

3. An automatic programming system accord- 
ing to claim 1 , wherein said program failure mode 5 
and effect analysis means includes a format pro- 
duction program for producing a format of an ana- 
lysis sheet for failure mode and effect analysis and 

a question generation process program for produc- 
ing and displaying questions for filling blank areas io 
of the obtained analysis sheet and filling blank 
areas of the analysis sheet with answers taken out 
from the designer. 

4. An automatic programming system accord- 
ing to claim 1. wherein said software design re- is 
viewing means has a design knowledge acquisition 

and learning function of extracting, design knowl- 
edges and rules from a result of processes of said 
program constitution trading-off means and said 
program failure mode and effect analysis means, 20 
and arranging the extracted knowledges and rules 
to produce a knowledge for design review concern- 
ing a software, the produced knowledge being 
stored in said knowledge base section, a design 
evaluation function of reviewing a design by using 25 
said knowledge for design review to point out in- 
defficiencies of the design and let the review reflect 
on design operations using said program constitu- 
tion trading-off means and said program failure 
mode and effect analysis means, and a design 30 
consultation function of retrieving the knowledge 
base section according to inquiries from the de- 
signer and indicating various data necessary for the 
design, said three functions being realized by inter- 
locked operations of said learning section, said 35 
knowledge base section and said inference section. 
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© Automatic programming system. 

© To automatize programming in a software devel- 
opment as much as possible, a trading-off operation 
for producing a program structure at the time of 
program design, a failure mode and effect analysis 
operation and a design review operation are all 
automatized, thus reducing time required for these 
operations. The design and test are directly coupled 
to each other so that design data at the time of 
design can be automatically utilized effectively at the 
time of test, thus saving man-hour for the test, 
reducing the test time and permitting effective pro- 
gramming, 
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